Skip to content

Conversation

quux00
Copy link
Contributor

@quux00 quux00 commented Oct 9, 2024

Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is be patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).

The new option is "include_ccs_metadata": true/false.

@quux00 quux00 added >non-issue Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) auto-backport Automatically create backport pull requests when merged :Analytics/ES|QL AKA ESQL v8.16.0 v9.0.0 labels Oct 9, 2024
@quux00 quux00 requested review from nik9000 and smalyshev October 9, 2024 17:40
@quux00 quux00 requested a review from a team as a code owner October 9, 2024 17:40
@quux00 quux00 requested a review from astefan October 9, 2024 17:40
Copy link
Contributor

github-actions bot commented Oct 9, 2024

Documentation preview:

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-analytical-engine (Team:Analytics)

@smalyshev
Copy link
Contributor

Couple of nitpicks, otherwise LGTM.

@quux00
Copy link
Contributor Author

quux00 commented Oct 9, 2024

When I add a new ESQL option/flag like include_ccs_metadata do I need to update the capabilities or features list?

And for that matter should the CCS metadata feature in general (added in earlier PR) be listed as either a capability or a feature in those classes?

Copy link
Contributor

@astefan astefan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In EsqlMediaTypeParser we make a validation that considers the a combination of format and the columnar parameter value in the sense that columnar doesn't make sense to be used with any format. I think include_ccs_metadata parameter is of the same type: it can only be used for json format and I think we need a similar check.

Map<String, Object> resp = runEsql(new RestEsqlTestCase.RequestObjectBuilder().query(query).build());
private Map<String, Object> run(String query, boolean includeCCSMetadata) throws IOException {
Map<String, Object> resp = runEsql(
new RestEsqlTestCase.RequestObjectBuilder().query(query).includeCCSMetadata(includeCCSMetadata).build()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using include_ccs_metadata only on this IT test suite is not enough I think.
Users can use include_ccs_metadata on any kind of REST request (multi cluster, single cluster single node, multi-node, mixed version, json/txt/tsv formats). I would, also, double check that "columnar": true (see this one in docs) still works with this new addition to the JSON response.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would, also, double check that "columnar": true still works with this new addition to the JSON response.

It does. I tested it manually and I have added a test to MultiClustersIT that uses columnar format with include_ccs_metadata=true and it is passing.

I think include_ccs_metadata parameter is of the same type: it can only be used for json format and I think we need a similar check

OK, I can add this restriction. If later we want to support it with SMILE, YAML and CBOR we can relax it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a restriction that include_ccs_metadata can only be used with format=JSON. Tests have been added / updated to match this restriction.

@quux00 quux00 requested a review from astefan October 10, 2024 17:50
}

private static void validateIncludeCCSMetadata(boolean includeCCSMetadata, MediaType fromMediaType) {
if (includeCCSMetadata && fromMediaType != XContentType.JSON) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's ok so long as the media type isn't text like the instanceof above. I expect kibana will use one of the binary ones at some point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, in the latest commit I've changed it to be like columnar and work with any XContent type.

Copy link
Contributor

@astefan astefan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one small addition, if you think it's worth it:

  • in x-pack/plugin/esql/qa/server/single-node/src/javaRestTest/java/org/elasticsearch/xpack/esql/qa/single_node/RestEsqlIT.java if you can add one test that doesn't use the ccs remote cluster format for indices. You could also simply adjust testBasicEsql() test method to receive a random value for include_ccs_metadata. This is to test a simple query like from test_index (no CCS involved) that behaves normally in the presence of include_ccs_metadata.

Thanks, @quux00 👍

Map<String, Object> resp = runEsql(
new RestEsqlTestCase.RequestObjectBuilder().query(query).includeCCSMetadata(true).columnar(true).build()
);
logger.info("--> query {} response {}", query, resp);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I'm still using that method to have a test that does both columnar: true and includes_ccs_metadata:true.

@quux00
Copy link
Contributor Author

quux00 commented Oct 11, 2024

@elasticmachine run elasticsearch-ci/part-3

@quux00
Copy link
Contributor Author

quux00 commented Oct 11, 2024

@elasticmachine run Elasticsearch Serverless Checks

@quux00
Copy link
Contributor Author

quux00 commented Oct 11, 2024

buildkite test this

@quux00
Copy link
Contributor Author

quux00 commented Oct 11, 2024

@elasticmachine run elasticsearch-ci/rest-compatibility

@quux00
Copy link
Contributor Author

quux00 commented Oct 11, 2024

@elasticmachine run elasticsearch-ci/validate-changelogs

@quux00 quux00 merged commit fd9d733 into elastic:main Oct 11, 2024
16 checks passed
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.x Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 114437

davidkyle pushed a commit to davidkyle/elasticsearch that referenced this pull request Oct 13, 2024
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).

The new option is "include_ccs_metadata": true/false.
@quux00
Copy link
Contributor Author

quux00 commented Oct 13, 2024

💚 All backports created successfully

Status Branch Result
8.x

Questions ?

Please refer to the Backport tool documentation

quux00 added a commit to quux00/elasticsearch that referenced this pull request Oct 13, 2024
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).

The new option is "include_ccs_metadata": true/false.

(cherry picked from commit fd9d733)

# Conflicts:
#	server/src/main/java/org/elasticsearch/TransportVersions.java
quux00 added a commit that referenced this pull request Oct 13, 2024
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).

The new option is "include_ccs_metadata": true/false.

(cherry picked from commit fd9d733)
stratoula added a commit to elastic/kibana that referenced this pull request Oct 16, 2024
## Summary

Retrieves the cluster details info on demand. Follow up of
elastic/elasticsearch#114437

This will display the cluster details info only when needed:
- Discover inspector
- Lens ES|QL charts inspector
kibanamachine pushed a commit to kibanamachine/kibana that referenced this pull request Oct 16, 2024
…6105)

## Summary

Retrieves the cluster details info on demand. Follow up of
elastic/elasticsearch#114437

This will display the cluster details info only when needed:
- Discover inspector
- Lens ES|QL charts inspector

(cherry picked from commit fbe15fe)
kibanamachine added a commit to elastic/kibana that referenced this pull request Oct 16, 2024
) (#196511)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[ES|QL] Retrieves ccs information for inspector on demand
(#196105)](#196105)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Stratoula
Kalafateli","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-10-16T09:39:00Z","message":"[ES|QL]
Retrieves ccs information for inspector on demand (#196105)\n\n##
Summary\r\n\r\nRetrieves the cluster details info on demand. Follow up
of\r\nhttps://github.com/elastic/elasticsearch/pull/114437\r\n\r\nThis
will display the cluster details info only when needed:\r\n- Discover
inspector\r\n- Lens ES|QL charts
inspector","sha":"fbe15fe7886102c1203c18ff87f3a0ea72e4b581","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","Feature:ES|QL","Team:ESQL","v8.16.0"],"title":"[ES|QL]
Retrieves ccs information for inspector on
demand","number":196105,"url":"https://github.com/elastic/kibana/pull/196105","mergeCommit":{"message":"[ES|QL]
Retrieves ccs information for inspector on demand (#196105)\n\n##
Summary\r\n\r\nRetrieves the cluster details info on demand. Follow up
of\r\nhttps://github.com/elastic/elasticsearch/pull/114437\r\n\r\nThis
will display the cluster details info only when needed:\r\n- Discover
inspector\r\n- Lens ES|QL charts
inspector","sha":"fbe15fe7886102c1203c18ff87f3a0ea72e4b581"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/196105","number":196105,"mergeCommit":{"message":"[ES|QL]
Retrieves ccs information for inspector on demand (#196105)\n\n##
Summary\r\n\r\nRetrieves the cluster details info on demand. Follow up
of\r\nhttps://github.com/elastic/elasticsearch/pull/114437\r\n\r\nThis
will display the cluster details info only when needed:\r\n- Discover
inspector\r\n- Lens ES|QL charts
inspector","sha":"fbe15fe7886102c1203c18ff87f3a0ea72e4b581"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Stratoula Kalafateli <[email protected]>
georgewallace pushed a commit to georgewallace/elasticsearch that referenced this pull request Oct 25, 2024
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).

The new option is "include_ccs_metadata": true/false.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Analytics/ES|QL AKA ESQL auto-backport Automatically create backport pull requests when merged backport pending >non-issue Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v8.16.0 v9.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants